Christopher James Huff wrote:
>In article <web.3dcd4ff566ca52347efeba520[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> If another function is declared and used by a new HF_ macro in order to get
>> another color channel that channel might tell the macro where to cut off
>> excess mesh to get the shape desired. I don't know if transmit and filter
>> channels can be easily made by all paint programs or if theres a way the
>> masks corel draw can make for .png files can be accessed (is transmit a
>> mask channel?).
>
>I think the best way would be a separate mask function. That way, you
>aren't limited to an image with an alpha channel. You could then use a
>user defined function to mask out parts of the image. (I don't even know
>how POV image maps handle alpha channels, I've never used it.)
>
>
>> All the colors make white, that shows up on all color channels, I think. So,
>> you'd have to do some sort of compare...
>
>Now I just couldn't figure out this sentence...

In my Corel photopaint I can separate the red, green and blue channels and
each each channel becomes a separate grey scale kind of picture. White and
black are the same on all channels and the difference in colors shows up
only in subtle variations in grey shades. A strongly red color is whiter in
the red channel and darker in the blue and green channels. If the red is
pure enough it's twice as bright as either blue or green.

>the colors of a height field image are not shades of gray.

I found out that you don't need to use the .hf dot operator, you can use
either .red, .green, .blue or .grey operators on color images and the HF_
macros work.

> The red and green channels are combined to get 16 bit precision out
> of 2 8-bit channels, the blue channel is ignored.
> You could probably use the blue channel for mask information,
> if that's what you are asking...

Ah, I picked the wrong color.

> it won't work if you then use a grayscale image, and it will limit
> you to image files unless you do some extra work to encode the mask
> into a pigment function.

Maybe the best way would be to let the user decide what they want to use.
Since the dot operator is chosen outside the HF_ macro it wouldn't matter
what the macro thought the channel was. That is, you could write any of
these:

#declare MeshCut = function {MyCutImage(x,z,y).red}
#declare MeshCut = function {MyCutImage(x,z,y).blue}
#declare MeshCut = function {MyCutImage(x,z,y).transmit}
#declare MeshCut = function {MyCutImage(x,z,y).grey}

to get a working function.

>> However, how does one express that cutting so that HFCreate_() can read it?
>> Will HFCreate have to be rewritten too?
>
>Probably.

I was afraid of that. This is getting more complicated the more I think
about it.

>For this you should probably write your own version, not
>modify the height field macros in shapes.inc, which could cause problems
>parsing other people's code.

Right. But that's not really what I meant. When I talking about "rewriting"
it has to do with the way I write code, I find other code that's close to
what I want and copy it to a new file, rename the function/macro/whatever,
and start making changes. Less typing, less re-inventing all the little
wheels that make it work.

The HF_macros may not actually be the closest to what I want, they're just
what I found and what people here know about (thanks to help from you
guys here I know that is). They can take a hand drawn image that was scanned
in and make a limited type of mesh. However, it's not exactly the
"sculpting with a pencil" idea I'm trying to implement. Warp may have
turned me on to some great "close" code, The Subdivision Surface Suite.

http://enphilistor.users4.50megs.com/sss.zip

normdoering

Post a reply to this message